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Overview 


The evolution of scientific spacecraft missions to constellations of nanosats will severely 
strain the capabilities of traditional legacy science data processing systems. Although 
ongoing advances in technology will allow for implementation of systems that will 
handle five to ten times the current processing load, the life-cycle cost to operate such 
systems will be prohibitive. We seek solutions that allow for less than linear scaling in 
cost-to-operate. 

A series of recommendations and approaches are presented. The most important of these 
is to become involved early in the planning phases of constellations, to ensure that the 
immensity of the problem of science data processing is not overlooked. Short-term band- 
aid class solutions abound. However, a new paradigm of science data processing for 
constellations consisting of hundreds of nanosats must be derived. 

The lack of hard requirements for science data processing from the many constellation 
projects examined is troublesome. It leads to the assumption that constellation projects 
are assuming that backend science data processing will scale, and that costs can be 
contained. This assumption is not at all obvious. 

Introduction 

This report discusses the requirements for Science Data Processing for constellations of 
nanosats. The primary problem to be addressed is control of development, deployment, 
and operational costs for multiple spacecraft As the paradigm for science and earth 
observing satellites shifts from large single spacecraft missions to those involving large 
numbers of smaller, inexpensive spacecraft, it is essential to control costs. The challenge 
is to contain the cost to process science data from 100 spacecraft; costs cannot be allowed 
to rise to 100 times that of a single spacecraft. 

Scope 

This report only discusses the area of the processing of science data from constellations 
of spacecraft. It does not discuss science or mission planning, or on-orbit operations for 
constellations. 

This report presents a snapshot of the possible requirements on science data processing 
for constellations. This is an ongoing project, and this report will be updated periodically 
as operational experience is gained with constellations. 
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The CMWG 


The Constellation Management Working Group (CMWG) was inaugurated by NASA- 
GSFC, code 580, the Information Systems Center in 1999. The key points of contact for 
the CMWG are Mr. Peter Hughes, and Mr. Gary Meyers. The central repository of 
information for the CMWG is the website implemented by QSS Group, 
http://CMWG.GSFC.NASA.GOV. 

The charter of the CMWG is to define the problems and challenges of formulation, 
implementation, and operation of a constellation of spacecraft and to recommend 
potential approaches to solving them. 

There are assumptions in the CMWG study. One of these is that current mission system 
capabilities and operation methods are inadequate for constellation missions. Another is 
that the majority of near-term constellation missions will implement homogeneous 
spacecraft. This is thought to simplify many issues. 

All four of the reference missions specify the same complement of instruments. In the 
near and medium term, homogeneous instrument sets are the norm. Although the 
instrument set will start out homogeneous, they will degenerate into heterogeneous in 
time, as equipment drifts, degrades, and fails. We can also consider the case of later 
spacecraft in the constellation having different instalments, based on experience with the 
early flights, and technology evolution. 

Constraints on the CMWG study include that total mission system development and 
operations costs for a constellation mission should NOT be linearly proportional in cost 
per spacecraft to that of current single spacecraft missions. It is highly desirable for the 
operations costs for constellations to be near the costs of current missions. 

The scope of the CMWG includes all data systems and operations activities for spacecraft 
constellation missions including: 

• Systems engineering 

• Ground segment and space segment to the extent that it affects operations 
manpower 

• Spacecraft integration and test Prelaunch operations preparation 

• Launch and early orbit 

• Routine operations including spacecraft and payload health and safety, command 
and control, data acquisition, and the management of the resulting engineering 
and science data. 

• Science data processing levels 0 - 4 

• Sustaining engineering 

Thus, the scope of the CMWG is much larger than the scope of this report. 
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Target Products and Results of the CMWG include a prioritized list of problems and 
challenges and recommended solutions for the formulation, implementation, and 
operation of spacecraft constellations. This list identifies target or prospective missions, 
need dates (near 0-3 years, mid 3-6 years, and far-term 7+ years) and the criticality of 
the need. 

Near/mid-term constellations 

Although there are commercial constellations deployed (Iridium, GlobalStar, and others), 
these are mostly communications constellations, and do not return science data. The 
CMWG defined four near to mid-term NASA constellation missions that would drive 
requirements. The missions considered by the CMWG are discussed below. 

The Nanosat Constellation Trailblazer Mission 


These are three very small satellites, called the Nanosat Constellation Trailblazer 
mission, selected as NASA's latest New Millennium mission. The mission will validate 
methods of operating several spacecraft as a system, and test eight technologies in the 
space environment near the boundary of Earth's protective magnetic field, or 
magnetosphere. Each Trailblazer spacecraft will be a small octagon 16 inches across and 
8 inches high, and each will have booms and antennas that will extend after launch. The 
mission will cost $28 million and will be launched in 2003 as a secondary payload on an 
expendable launch vehicle. 

Results from the Trailblazer mission will be used to design future missions using 
constellations of lightweight (about 44 pounds), highly miniaturized autonomous 
spacecraft. One proposed constellation of up to 100 spacecraft positioned around the 
Earth will monitor the effects of solar activity that can affect spacecraft, electrical power 
and communications systems. Others will study global precipitation and the atmospheres 
of other planets. 

The Nanosat Constellation Trailblazer is the fifth in NASA's New Millennium program, 
which tests technology for future space and Earth science missions. The program's goal is 
to dramatically reduce the weight, size and costs of missions while increasing their 
science capabilities. 

The impact of 3-5 very small satellites on science data processing is minimal, but the 
current project is just a trailblazer for larger constellations, perhaps of 100 or more 
members. The scalability of current science data processing systems to 100 input data 
streams is unknown, but highly unlikely, without prohibitive cost. 

Constellation-X 


The Constellation-X Mission will consist of a group of X-ray telescopes in space, 
working in unison to improve the view of the X-ray universe by a hundred-fold. The 
mission is a key element in NASA's Structure and Evolution of the Universe theme, 
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dedicated to unlocking the mysteries of black holes, galaxy formation and the Universe's 
still undetected matter. The mission planning is in an early stage, and no specifics could 
be found on data processing requirements. As a placeholder, the science data processing 
will be assumed to be an extrapolation of that of "typical" X-ray, high energy missions. 

ST-5 


The Magnetotail constellation mission is also known as DRACO - Dynamics, 
Reconnection, and configuration observatory. The following is abstracted from the 
Report of the NASA Magneto spheric Constellation V Science and Technology Definition 
Team: 

"Magnetotail Constellation DRACO is the Solar Terrestrial Probe (STP) mission 
designed to resolve controversies concerning the complex dynamics of the magnetotail. 
To achieve observational closure with theory, we must distinguish spatial structures from 
temporal variations throughout the magnetotail. This requires a large number of small yet 
highly capable spacecraft, creating a station network capable of resolving 2 RE scales at 
10 sec time resolution, over a 15 x 30 RE domain." Neither current single spacecraft, nor 
even tight groups of spacecraft, are sufficient to resolve these theoretical controversies of 
the magnetotail. 

"DRACO will provide the first global time-evolving maps of fields and flows in this 
important region. Using recently available technologies, the magnetotail can now be 
reached with a swarm of small spacecraft. Such a swarm is novel in its ability to 
simultaneously resolve magnetic fields and flows throughout large volumes of the 
magnetotail. DRACO is designed to provide the groundbreaking data needed to 
understand how the magnetotail really functions." 

Again, the data processing requirements from 5 spacecraft will not necessarily 
overwhelm current systems. The key is to contain operations costs. 

MMS - Magnetospheric MultiScale (Constellation) 

MMS is approved as part of solar terrestrial probes (STP) program. It is scheduled to 
launch in 2006/2007. The mission is cost-capped at $120 M for phases C/D 

There will be 5 spacecraft, each spin stabilized, formation flying in a double tetrahedron. 
All launch at same time from expendable launch vehicle (Delta class). Intersatellite 
communications will be used for ranging and for alarms to trigger high data rate 
recording mode. The orbits vary by mission phase: 

• Phase I - 1.2 x 12 RE, 1=10 degrees, period = 24 hours 

• Phase II - 1.2 x 30 RE, 1=10 degrees, period = 3.6 days 

• Phase III - 8 x 80 RE, I = TBD, period =14 days 

• Phase IV - 10 x 50 RE, I = 90 degrees, period = 5.2 days 
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The downlink data rate is 1.5 Mbps, with a data volume of 2Gbits/day. Data dumps 
during Phases II-IV will occur at 2.2 Mbps when the spacecraft is closer than 29 RE. 

Routine Operations will be conducted for 2 years nominal, with on-board attitude 
determination. The spacecraft will be supported sequentially by ground stations, with 
USN support (command, telemetry, tracking, science data dumps) during Phases I and II; 
tracking support only during Phases III and IV. DSN support will be used during Phases 
III and IV (command, telemetry, tracking, and science data dumps). 

Science Processing will consist of LZP. Beyond this, the science data processing is not 
specified. 

Additional Constellation projects 

In addition to the missions being considered by the CMWG, the following additional 
constellation projects were examined for requirements for science data processing: 

The University NanoSat Program 

Utah State University, University of Washington, and Virginia Polytechnic Institute are 
designing and developing a system of three 10-kg spacecraft to investigate satellite 
coordination and management technologies and distributed ionospheric measurements. 
The three will coordinate on satellite design, formation flying, management mission 
development, and science instruments and mission. An Internet-based operations center 
will be designed to enable each university to control its satellite from its own remote 
location. 

One objective of the program is the understanding of ionospheric density structures that 
can impose large amplitude and phase fluctuations on radio waves passing through the 
ionosphere. The constellation provides a unique opportunity to answer questions about 
ionospheric disturbances that can not be addressed any other way. A single satellite can 
only provided very limited information on the dimensions and evolutionary time scales of 
the ionospheric disturbances it flies through because a full orbit (90 minutes) must occur 
between the next observation. In general the situation is even worse than this because 
only truly zero inclination equatorial satellites have a good possibility of measuring the 
same region twice due to the co-rotation of the ionosphere with the Earth. This science 
investigation contributes to the TechSat 21 basic research mission of investigating global 
ionospheric effects which affect the performance of space based radars. It also addresses 
broader Air Force interests in ionospheric effects on navigation and communication links. 

The nanosat constellation will be used to make the first global multi- satellite electron 
density measurements in the ionosphere. We also propose to make the first global multi- 
baseline RF-scintillation measurements of the ionosphere. The scintillation of GPS 
signals using receivers on each spacecraft will provide information about the scale sizes 
of disturbances between the nanosatellite constellation and the GPS transmitter. 


6 



One of two possible instruments will be deployed on each of the satellites in the 
constellation, either a plasma frequency probe from which an absolute electron density 
can be determined or an electron saturation current probe which can measure relative 
electron density variations. The instalment to be selected will be based on the resources 
available on the nanosat but in general these instruments will be small, low-power, and 
have low impact on their host satellites. 

The scintillation measurements will be extracted from the GPS receivers that are part of 
the orbit determination system on the nanosats. The 1575 MHz signal from the GPS 
satellites originate at 20,000 km over the Earth and must travel through the ionosphere, 
line of site, to the location of the nanosats at 360 km altitude. The signal will encounter 
regions of disturbed ionospheric plasma which will slightly increase or decrease the 
signal strength at the receivers. The size of these disturbed regions can be estimated by 
comparing signals measured over closely related propagation paths, such as between two 
nanosats. 

The basic satellite design is configured for released from a Shuttle Hitchhiker canister. 
The structure is hexagonal with an approximate 18 in. width and a 5 in. height. This 
configuration can be modified as needed to meet the specific launch environment 
conditions. The power regulation electronics will leverage high quality commercial NiCd 
batteries which have been developed commercially for portable laptop computers. 

Ground Operations via Internet: The USU ground station will be used for ION-F, and 
another ground station, most likely at VT, will be developed. In order to successfully 
coordinate the three satellites, an Internet based ground station will be developed. This 
will allow coordination of experiments by the different universities as well as individual 
satellite control and data dissemination. VT is also investigating use of the GlobalStar 
LEO constellation for satellite telemetry, tracking and commanding of the satellite using 
commercial communications technology. 

Commercial remote- sensing constellations 

A number of commercial constellations have been deployed. These deployed systems 
address the voice, broadband data, messaging, navigation, and remote sensing markets. 
This report focuses only on the remote sensing constellations. 

OrbYiew 


Orbital Imaging ( http://www.orbimage.com/main/main.html )has two remote- 
sensing satellites onorbit and are to launch another two. OrbView-1 was successfully 
launched on April 3, 1995. The satellite provides daily severe weather images, global 
lightning information and atmospheric monitoring to improve long-term weather 
forecasts. Orb View-2 was successfully on August 1, 1997 by OSC's Pegasus rocket. 
OrbView-2 offers broad-area multispectral imagery of both land and ocean regions. 
OrbView-3 is scheduled for launch in 2000. Satellite constniction is underway by 
Orbital’s Space Systems Group at its McLean, VA facility. OrbView-3 will offer one- 
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meter panchromatic and four-meter multispectral digital imagery. Orb View-4 is 
scheduled for launch in 2000. Satellite development is underway by Orbital’s Space 
Systems Group in Germantown, MD. Orb View-4 will offer one-meter panchromatic, 
four-meter multispectral, and hyperspectral digital imagery. 

RocSat-3 


The Taiwanese government has apparently also announced that Rocsat-3 will be a 
constellation of six satellites for remote sensing. No further details are available. 

COSMO/SkvMed 

COSMO (CO nstellation of small Satellites for Mediterranean basin Observation) is a 
program conceived and defined by Alenia Aerospazio - Finmeccanica S.p.A. to promote 
the use of satellite remote sensing. The project will predominantly provide dedicated 
services to the communities living around the Mediterranean Sea. The COSMO program 
also integrates the Italian SkyMed mission, conceived by Fiar and OfficineGalileo. 
COSMO/SkyMed is the first and only constellation implementing both optical and radar 
satellites in optimized orbits, capable of fully meeting the challenging requirements for 
advanced applications dedicated to the management and control of Mediterranean basin 
resources. 

The technical features of the COSMO/SkyMed satellite system are particularly tailored 
for near real time applications. Urban monitoring and civil work are made possible by the 
high frequency revisiting time combined with day-night - all weather operation. High 
ground geometrical resolution and stereo capabilities will allow an almost permanent 
control of the urban and rural areas. Cosmo/SkyMed high resolution images (2.5 m in the 
optical/panchromatic band and 3 m with the SAR sensor) will facilitate making new 
maps and updating older ones. The in-track stereo capability of the optical high resolution 
camera can be used for digital elevation maps. 

The day-night and all weather observation capabilities of the SAR constellation will 
make it possible to implement new forms of control from space of violations of 
international codes and/or infringements of national laws. The constellation’s observation 
capabilities in the optical and radar bands, combined with the short revisiting intervals, 
will prove to be a formidable asset for disaster monitoring and damage assessment. This 
will particularly apply to natural disasters like earthquakes, floods and fires - with 
important contributions in the case of other meteorology-related disasters - as well as to 
disasters caused by man. The fully ground commandable, multispectral imager and the 
I.R. sensor will greatly contribute to the determination of pollutants, supported, for 
specific targets like oil spills, by the SAR sensor. 

The I.R. camera and the VIS/NIR imager can provide a better insight into the status of the 
coasts. Combining the high geometrical resolution of the panchromatic sensor with the 
coarser resolution of the other sensors results in innovative added-value products. Certain 



analysis bands have proven to be inadequate for distinguishing different crop types. The 
I.R. and VIS/NIR imager can dramatically improve the quality of the end user products . 

The unique COSMO/SkyMed features can further enhance the growth of commercially 
exploitable services in several applications: 

• civil protection 

• transport 

• geology 

• tourism 

• insurance 

• hydrological resources. 

Although designed to satisfy the needs for advanced management of Mediterranean basin 
resources, the COSMO/SkyMed system could well be exploited for similar applications 
in other areas. It is planned to establish a commercial network on a global basis, sharing 
with other regional partners the resources made available by the COSMO/SkyMed 
system. 

Three optical satellites are equipped with the following main sensors: 

• a high resolution panchromatic camera 

• a coarse resolution multispectral imager 

• a medium resolution infrared camera (l.R.) 

• four SAR satellites equipped with an X-band (9.6 GHz) Synthetic Aperture Radar 

A high data rate transmission facility, operating at X-band via mechanically re-pointable 
directive antennas, serves for direct transmission of the data generated by the high and 
medium resolution sensors. X-band Data Receiving stations are equipped with moderate 
size antennas, less than 3 m in diameter. 

A low data rate S-band transponder via a wide beam antenna, is dedicated to several 
operations: 

• retransmission of on-board stored data to small terminals 

• gathering data transmitted from ground-based sensors 

• implementing @-mail in a store-and-forward communication 

The COSMO/SkyMed ground segment includes: 

• Constellation management infrastructure (Mission Control Centres and Satellite 
Control Centres) 

• Decentralized ground-based user facilities for direct data collection from the 
satellites 

• Centralized archiving facility. 
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The management of the COSMO/SkyMed constellation will make use of multiple 
Satellite Control Centres linked to the Mission Control Centre in a star configuration. 

A flexible and cost-effective solution implements the following features: 

• reception of data directly from overpassing satellite via an X-band communication 
link for the high-speed data channel and/or via an S-band communication link for 
the low-speed data channel 

• a "store-and-forward" data service in S-band, using the satellites of the 
constellation 

• a standard data processing facility 

• a special purpose data processing package 

• interface with the Mission Control Centre for satellite resource allocation and 
planning 

• interface with the archiving facilities. 

Stations can be configured to be transportable to meet specific logistic requirements. 
Within the framework of the COSMO/SkyMed program it is planned to implement the 
National Data Receiving Processing and Centralized Archiving Centre(s) to serve, at 
regional level, the users not equipped with direct access to satellite data. Note that very 
few specifics were mentioned for COSMO/SkyMed science data processing. 

Tsinghua Constellation 

Surrey Satellite Technology Ltd (England), a University of Surrey company, and 
Tsinghua University (China) have formed a Collaborative Joint Venture company in 
Beijing to develop advanced microsatellites for China. A market for over 100 small 
satellites over the next 5-8 years has been identified within China and SSTL is the first 
foreign company to establish a joint venture in this market, accessing business worth 
some £300 million. 

The 25-year joint venture company, to be known as the "Tsinghua-Surrey Small Satellite 
Company (T-SSSC)", is the result of more than five years extensive work by SSTL in 
China promoting the use and applications of sophisticated small satellites as a more rapid 
and lower cost approach to meeting China’s space requirements. The formation of this 
first private satellite manufacturing company in China reflects the desire of the 
government to introduce increasing commercial market forces into the Chinese space 
industry. 

"This is a world-first breakthrough for a British company into the closely-controlled 
Chinese satellite industry and we look forward to working with Tsinghua to develop 
small satellites for the Chinese market", said Professor Martin Sweeting, Director of the 
Surrey Space Centre and CEO of SSTL. 
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The first £3 million contract for T-SSSC has already been signed between Surrey and 
Tsinghua for a 50kg microsatellite (to be called Tsinghua-1) which will form the first 
demonstrator for a constellation of seven microsatellites to provide daily world-wide high 
resolution imaging for disaster monitoring and mitigation, planned for launch in 2000. 
The microsatellite will also carry out communications research in low Earth orbit at the 
end of 1999 after launch on a Chinese Long March rocket. 

In September, 1998, the Surrey Space Centre and the Tsinghua Aerospace Centre also 
launched a joint "Tsinghua- Surrey Small Satellite Research Centre" which will specialize 
in advanced academic research and development of microsatellite and nanosatellite 
technologies. 

No details were provided on the processing of the science data from the Tsinghua 
satellites. 
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Approaches 


Based on an evaluation of the above-mentioned constellation projects, and noting the lack 
of hard requirements in any of these, the following approaches are suggested to meet the 
oncoming requirements for Science Data Processing of constellations of nanosats. In 
almost all cases, the constellation projects are vague in their requirements for data 
processing. This is most likely because they are making the assumption that legacy 
systems will scale to meet their requirements, without a significant increase in costs. It 
will become critical to become involved early in the planning and requirements phase of 
the constellation projects, to ensure that data processing requirements are being properly 
considered. The constellation projects seem to be focusing on the hard, up-front 
requirements for care and feeding of a hundred spacecraft, mission planning and re- 
planning, mission ops, orbit and attitude determination. The commercial projects, either 
because they return no science data, or because they are very early in their planning 
stages, have provided no guidance in the science data processing area. 

1. Take advantage of advances in basis technology 

Computers will become faster and cheaper into the foreseeable future. Processor speeds 
and memory densities have yet to hit a wall, and continue to follow Moore's law without 
a discemable leveling of the rate of technological advance. However, the mere increase in 
speed, memory, and I/O capacity will not suffice to contain costs for processing of 
science data for advanced constellation missions. It may be possible to processes 5 or 10 
times the amount of data that present-day missions produce, for the same or less cost. 
However, this process does not the scale to 100's of data-retuming spacecraft. 

The impacts of processing larger numbers of spacecraft, and larger data sets, are not 
constellation-unique. We can expect increased workload in all these areas, constellations 
or not. The "March of Technology" will solve some of these problems. The cost of 
computing power and storage (even for on-orbit systems) is trending towards zero. 
Transmission costs are also trending to zero, albeit at a slower rate than processing power 
or storage costs. Alternatives such as Internet from commercial section and growth of the 
ground-based optical infrastructure provide new lower cost options for moving data from 
sensor to end-user. 

Alternates to CCSDS such as use of TCP/IP may eliminate or reduce need for LZP. This 
is the thrust of the end-to-end satellite networking concept. This should also serve to 
reduce life-cycle costs. 

2. Take advantage of parallel processing approaches 

Any given data processing architecture will have bottlenecks, because either the 
processor is waiting for the memory (processor stall), or the memory or I/O subsystem 
are waiting for the processor (I/O bound). Communications speed is limited by the 
minimum channel capacity in the system, and processing speed is limited by the slowest 
hardware element. Ideally, the computation rate should balance the I/O rate, but this is a 
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function of the problem domain, and the algorithm. Processing speed is increasing (and 
has historically) because of increasing clock rates, decreased feature size, and more 
advanced architectural techniques (superpipelining, superscalar, rise). This trend will 
continue into the near future, until fundamental physical barriers are met (speed of light, 
atomic feature size, quantum effects, etc). I/O capability has not scaled as well. Memory 
capacity has scaled, but still lags computational complexity. 

As a general principle, the computation rate should balance the I/O rate. Consider a 
computational problem, for example, image texture analysis, that requires more resources 
than a single processor can provide. In adding a second or subsequent processors, we 
achieve diminishing returns in processing power, because we have created 
communication requirements between processors with bandlimited channels. Ahmdahl's 
Law says we get less than 1 unit of incremental processor power per added processor. In 
most real designs, the curve of incremental processor power per added processor displays 
a sharp fall-off. In a well-balanced system each added processor can add nearly a 
complete increment of processing power to the system. This is the limitation that parallel 
processing systems hit. This is an architectural issue, and each processing algorithm has 
inherent computational and I/O requirements, and associated bounds. Understanding 
these allows for the scaling of systems without wasting resources. 

We need to examine the scalability of representative and legacy science data processing 
algorithms, to device systems that do scale properly across N datasets. In terms of 
ground-based processing, we can think of passing the various instrument datasets through 
the same pipeline, and posting in the same databases. The concept of object-orientation 
applies, where the top level object is the constellation, the next level down is the 
spacecraft, the next level is the instrument. 

The processing of multiple datasets through the same pipeline requires us to determine 
the processing and I/O requirements of the pipeline implementation, and its scalability. 
First guess would be that the pipeline scales linearly in time - 10 datasets takes 10 times 
as long with the same hardware, or the same time, on hardware that is 10 times faster (in 
CPU and I/O capability). The example is the OPUS pipeline, developed for HST, used on 
FUSE, and being looked at for SWIFT. We have implemented this on a Linux box in the 
Code 586 lab. 

The impact on science data processing is to determine the scalability of current science 
data processing systems, to determine if they are applicable to constellations. The fact 
that the instrument set is homogeneous in the near term helps. The issues are to examine 
the science data processing with respect to processing and I/O requirements. If the 
algorithms and processes are computationally limited, then faster or scaled underlying 
hardware is the answer. If the algorithms are more I/O bound, the situation is more 
complicated. I/O channel bandwidth does not scale as linearly as does computational 
horsepower. 

3. Migrate some data processing onboard 
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There is the same trade-off with members of a constellation as with individual spacecraft 
on onboard versus ground based processing of science data. Migrating some of the 
processing of data onboard (where resources are more expensive) makes sense if 
downlink bandwidth/availability is a more costly resource. The problem comes more into 
focus when we are talking about a lOOx problem. 

We can investigate and advocate moving more of the routine science data processing 
onboard. This mitigates some of the downlink problem, and simplifies the ground based 
resources required. How do we avoid complicating the onboard problem? If portions of 
the science data processing can be instantiated in reconfigurable hardware onboard, the 
incremental costs are driven low. Reconfigurable hardware provides the economy of 
scale and speed of hardware, avoiding the lock-in problem by being changeable. 

4. Develop more automated processing 

The aggregate data volumes and rates issue is not constellation unique. We can safely 
predict that, constellations or not, science data processing will be faced with handling 
rapidly increasing data set sizes and rates. This forces the questions of scalability of 
communication, computation, and data storage resources. 

For science data distribution, we must be concerned with data archiving, data security 
and privacy, timely data access - non of these are constellation-unique. We should 
continue to investigate methods of data dissemination - web-based is the technique du 
jour. Is this what the experimenters want? Are CD/DVD technologies applicable? Where 
are the bandwidth/storage trades in the system? How are these affected by the 
deployment of constellations? 

Recommendations 

1. Continue to collect and track requirements for constellation science data processing. 
As the constellation missions get closer to launch, their requirements will hopefully firm 
up. Try to get involved with the projects to drive the consideration of the science data 
processing tasks. 

2. Continue to track the basis technology, that will give less than order-of-magnitude 
increases in processing power, memory capacity, and I/O bandwidth. This is the short 
term solution. 

3. Continue to explore and prototype technologies for science data processing that will 
scale to hundred's of input sources. These may include the OPUS Science Data Pipeline 
from STScI. Hosted under Linux, it scales across multiple hosts with the Code-900 
developed Beowulf technology. The major cost driver for processing will not be the 
installed cost of the systems, but in their operation. Automation of the processing is a 
must. 
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The following is from the Report of the NASA Magnetospheric Constellation Science 
and Technology Definition Team: 

"It is widely recognized that the data sets generated by constellation missions require data 
management and handling techniques that are outside the current experience with space 
missions. Nevertheless, the problem is not qualitatively different from that associated 
with the conduct of atmospheric meteorology research and monitoring." 

"The most fundamental problem is the visualization of both scalar and vector field 
information from a large number of observing stations. Some techniques developed for 
meteorology will be directly transferable to use with constellation data sets. Others will 
require new techniques, for example the visualization of magnetic field information that 
is not present in atmospheric meteorology." 

"The next step beyond basic visualization is the assimilation of the data into global 
circulation models. This will allow for instantaneous comparison with such models, 
extrapolation of the observations into other parts of the system outside the constellation, 
and projection or forecasting of system behavior for comparison with actual observed 
system evolution. This is a complex process, which has been discussed in much more 
detail in the section on science objectives, above." 

"Because the treatment of constellation data is so foreign to space physics, there is a 
significant need for the development of appropriate tools, borrowing wherever possible 
from prior work along the same lines that has already been completed in meteorology. As 
an integral part of the technology development effort for DRACO, developments along 
these lines should be supported at appropriate institutions with expertise in visualization 
and assimilation of data. Researchers who are active in the global simulation of 
magnetotail processes should undertake a significant amount of this work. They are in a 
position to generate simulated data sets, to introduce realistic errors in them, and then to 
develop the means to r-assimilate the simulated data back into the same model that 
generated it, or other independent models." 

4. Continue to investigate migration of routine science data processing onboard the 
spacecrafts, either taking advantage of better onboard computing resources, or using 
reconfigurable computing/FPGA technologies. 
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